Modern integrated circuit (IC) devices are substantially more complex and sophisticated than early IC designs. Early IC chip designs typically embodied relatively simple electronic logic blocks formed by interconnections between logic gates. In contrast, modern IC chips often include combinations of memory and application-specific integrated circuit (ASIC) components surrounding an embedded processor (often called a “central processing unit (CPU) core”), which together constitute an entire “system-on-a-chip” (SOC) device. Exemplary SOC devices are designed and produced using architectural tools and libraries associated with the TriCore™ family of processor devices, which is the property of Infineon Technologies AG of Munich, Germany.
The development of SOC IC device (as well as less sophisticated ASIC devices) includes a design phase, which includes simulating and verifying a circuit design using a high-level (e.g., Register Transfer Level (RTL)) hardware description language, a place, route and layout phase for determining the physical arrangement of the components and wiring associated with the verified circuit design, and forming the physical circuit layout that is fabricated onto a semiconductor wafer. The design phase typically involves selecting and defining a high-level software model of the circuit design that may include various predefined model components (e.g., CPU core, data and program memory circuits, cache memory, etc.) from a design library using software tools available from the SOC/ASIC provider (e.g., Infineon Technologies AG). A device simulator tool (“simulator”) is then used to test the circuit design model by simulating the execution of selected test programs. The results of these simulations are used to verify that the circuit design model will function as intended, or used to debug and correct errors in the circuit design model. This simulation and verification process has been increasingly relied on by SOC device manufacturers to reduce time-to-market delays, and to avoid prototyping costs. Once the circuit designer is sufficiently confident that the SOC design is accurate, the SOC design proceeds to the place/route/layout and fabrication stages of production.
While the use of simulators to verify and debug circuit designs greatly decreases manufacturing costs by minimizing costly design flaws prior to fabrication, there are several practical problems that limit the use of simulators to achieve acceptably bug-free SOC designs. In particular, in order to verify that a SOC design is substantially bug-free, the execution of a sufficient number of test programs must be simulated to adequately exercise the design. One practical problem associated with the verification of SOC designs is the magnitude of information being processed and stored during these multiple simulations. Another problem is that modern SOC designs often have several hundred thousand to millions of memory cells associated with the embedded processor, and identifying errors in the reading (loading) and writing (storing) of data to/from these memory cells makes analyzing and debugging SOC designs using the simulation results extremely time consuming and complex. This problem is mainly produced by the fact that the data in the memory cells typically has a long history (i.e., is repeatedly updated over the course of the test program), in contrast to the processor core (a.k.a., the CPU pipeline), which normally only has a sequential history as deep as the pipeline itself. The long history associated with memory cells creates problems during the debugging process (i.e., analyzing the simulation results when bugs are detected) because the task of tracking the contents of thousands of memory cells over thousands of lines of code, and then presenting the memory contents in a meaningful fashion greatly challenges the capacity of modern computers, and, even more importantly, the designer's ability to read, check and verify the vast amounts of simulation data generated by the computer.
The complexity associated with verifying SOC designs is further complicated in view of the fact that, in a DSP architecture such as that found in TriCore-based SOC devices, the memory system does not just consist of one single 2-dimensional memory array that can be traced and viewed, but rather consists of multiple memory arrays that contain data tiled in both directions, and sometimes even scrambled and interleaved. This tiling, scrambling and interleaving is used to achieve optimal timing and floorplanning results in a physical-level data accessing domain, but certainly increases the need for debugging due to its higher architectural complexity (and therefore increases the chance of bugs), and also due to reduced observability. Tiling is also used to access several of these memories with different address rows so that accesses spanning one physical line become possible. TriCore supports such unaligned accesses. Also TriCore allows different widths of the data objects accessed. To save power only those memory elements that are needed for an access of a certain width can then be activated, which could not be supported by one single (wide) memory. Further complexity arises when additional write first-in first-out (fifo) memories are used between the CPU and the memory system that complicate the memory system's debug process.
Conventional debugging of SOC designs is typically focused on the physical memory cells of the SOC's memory arrays, and typically display physical-level memory information using waveform viewers. A problem with this arrangement is that, to debug memory systems in such SOC designs, a circuit designer would have to look at the contents of several thousand memory cells and/or interfaces of several memories and write buffers to determine the exact memory content, and would have to observe the waveforms bit by bit, and simulation step after simulations step, to determine which macro-transactions are occurring, how wide the transactions are, and which memories the transactions involve.
Another conventional debugging approach reads and stores the entire contents of the SOC memory after each transaction (e.g., write operation). A problem with this approach is that it is very time consuming to read and store every memory location during a simulation including thousands of regression tests, each regression test including thousands of transactions. In addition, modern SOC designs typically include memories storing thousands of bytes of information. Therefore, another problem arises with respect to the capacity of a workstation for storing the entire memory contents over thousands of transactions and thousands of test programs, which can become overwhelmed with the large amount of data. A final problem is the practical issue of processing the large amount of data generated by this method.
What is needed is a more effective method for simulating and debugging SOC designs that avoids the capacity problems associated with conventional debugging/simulation techniques, while providing high-level views of memory activity during operation, and automatically self-checking portions of the data that can be automatically checked.